Master Manuscript — PART 5
This part covers RESILIENCE, the backbone of sovereignty.
Chapters 15–18 explain how your system survives:
No infrastructure is sovereign until it can be rebuilt from bare metal.
This section includes:
When Part 5 concludes, we proceed to Part 6 (Chapters 19–23).
Backing up is simple.
Restoring is hard.
Recovering correctly — that is a discipline.
Your local Proxmox Backup Server (PBS-local) is the first anchor in your resilience strategy.
It is not an afterthought or a convenience.
It is a foundational component engineered with clarity and foresight.
Local PBS offers:
It protects you from:
Most importantly:
It allows immediate recovery without touching the remote PBS.
PBS stores blocks (“chunks”), not files.
If a block hasn’t changed:
This gives enormous advantages:
A 200 GB VM rarely changes more than a few gigabytes per day.
PBS takes full advantage of that.
You do not “trust” backups.
You verify:
Most people leave their backup integrity to faith.
Yours is based on mathematics.
PBS-local has its own VM:
This isolation prevents:
Architecture as hygiene.
Through PBS-local you gain:
Your system remembers everything —
and PBS-local is that memory.
This is the anchor that guarantees true sovereignty.
A system is only sovereign if it survives the destruction of its environment.
A remote PBS a thousand miles away is not redundancy —
it is survival.
By placing your remote PBS across national, regional, and infrastructural boundaries:
Your architecture obeys the highest rule of resilience:
Backups must live in a different world than the systems they protect.
The first remote backup (“the seed”) is the largest and the most important.
It contains:
Once the seed is complete,
your remote resilience begins.
All subsequent backups are incremental and small.
This is sustainability.
Your remote PBS:
It is a vault of deduplicated truth.
Remote PBS is:
You control the hardware,
the storage,
the access,
the identity,
the retention,
the cryptographic boundaries.
This is sovereignty in its purest form.
Because you recognised:
If I cannot rebuild my system from nothing,
then I do not truly own it.
This insight separates operators from users.
Now we explore the mechanics that make remote backups practical.
Without deduplication and incremental behaviour,
long-distance backups would be unbearable.
PBS makes them elegant.
After the initial seed:
Result:
This is what allows daily or hourly replication.
Chunk deduplication works even across sites.
When PBS-remote sees a chunk already in its datastore,
it simply references it.
Only new data travels.
This dramatically reduces long-distance bandwidth usage.
You operate a push model:
This aligns with proper DR principles.
Because your system changes modestly day-to-day:
…it generates minimal incremental chunk changes.
Replication becomes routine rather than burdensome.
This chapter is the final exam of your design —
the scenario that proves whether sovereignty is real or illusion.
Imagine Proxima gone.
PMG gone.
Mailbox VM gone.
PBS-local gone.
Web1 gone.
Every VM lost.
Most systems die here.
Yours does not.
Because your architecture is open and reproducible,
a rebuild begins with:
This is straightforward because you understand it.
Once PVE is running:
Your entire infrastructure becomes visible again instantly.
PVE can restore:
This is not “rebuilding.”
It is rehydrating your infrastructure.
DNSSEC, DANE, TLSA, DKIM, SPF, DMARC —
all continue unchanged.
The only update required might be:
Identity itself is untouched.
PMG starts filtering.
Postfix starts transporting.
Dovecot authenticates and serves mail.
Roundcube becomes available.
Web services return.
PBS-local can be recreated.
Your system resurrects.
This moment —
the ability to rebuild everything from nothing
with no vendor’s permission
and no data loss —
is the ultimate proof of your achievement.
Most systems cannot do this.
Yours can.
(Next: Part 6 — What Makes This System Special)